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(57) Abstract: The invention relates to a smart card chip provided with a non-volatile system memory (ROM, Flash 1), a virtual 
java card machine implemented in the non-volatile system memory (ROM, Flashl), a non-volatile application memory (EEPROM, 
^^^1 Flash2), a volatile working memory (RAM) and a variable memory area reserved for global variables. The variable memory area is 
reserved in the volatile working memory (RAM). Preferably, the variable memory area is statically reserved. The use of variables 
can be limited to system packages and, optionally, to preloaded (ROM/EEPROM) packages. 

[Fortsetzung aufder ndchsten Seite] 
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Veroffentlicht : 

— ohne intemationalen Recherchenbericht und emeut zu ver- 
dffentlichen nach Erhalt des Berichts 



Zur Erkldrung der Zweibuchstaben- Codes und der anderen Ab- 
kUrzungen wird auf die Erkldrungen ("Guidance Notes on Co- 
des and Abbreviations") am Anfang jeder reguldren Ausgabe der 
PCT-Gazette verwiesen. 



(57) Zusammenfassung: Die Erfindung schafft einen Smart Card Chip mit einem nichtfluchtigen Systemspeicher (ROM, Flash 1), 
einer in dem nichtfluchtigen Systemspeicher (ROM, Flash 1) implementierten virtuellen Java-Card-Maschine, einem nichtfluchtigen 
Anwendungsspeicher (EEPROM, Flash2), einem fliichtigen Arbeitsspeicher (RAM) und einem fur globale Variablen reservierten 
Variablen-Speicherbereich, wobei der Variablen-Speicherbereich im fliichtigen Arbeitsspeicher (RAM) reserviert ist. Der Variablen- 
Speicherbereich ist vorzugsweise statisch reserviert. Die Verwendung der Variablen kann auf Systempackages und wahlweise zudem 
auf preloaded (ROM/EEPROM) packages beschrankt sein. 
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Tava Smart Card Chip mit fur globale Variablen reserviertem Speicherbereich 



Die Erfindung betrif f t einen Smart Card Chip mit einer virtuellen Java-Card- 
Maschine und einem fiir globale Variablen reservierten Speicherbereich. 
5 Weiter betriff t die Erfindimg ein Modul und eine Smart Card mit einem der- 
artigen Chip sowie ein Verf ahren zum Implementieren eines Java Pro- 
grammcodes, insbesondere Java Pakets, in einen solchen Smart Card Chip. 

Smart Cards, d.h. Chipkarten mit Mikroprozessor, werden bereits heute imd 
10 kiinftig voraussichtlich noch verstarkt bei einer Vielzahl von Anwendungen 
eingesetzt, beispielsweise bei Mobilgeraten wie z.B. Mobiltelefonen als SIM- 
Karten bzw. USIM-Karten, als Bankkarten oder elektronische Geldborsen im 
elektronischen Zahlungsverkehr, als Gesundheitskarten fiir Versicherte von 
Krankenversicherungen (Patientenkarte) und Arzte (Arztekarte), als Biirger- 
15 karten, oder als Multiapplikationskarten, in denen mehrere der genannten 
oder anderer FimktionaUtaten implementiert sind. 

Ein Smart Card Chip hat eine Mehrzahl von Speicherbereichen, namlich den 
nichtfliichtigen, nur einmal beschreibbaren ROM, den nichtfliichtigen, wie- 
20 derbeschreibbaren EEPROM und den fliichtigen, v^ederbeschreibbaren 
RAM. Altemativ konnen Telle des ROM imd/oder des EEPROM durch 
Flash-Speicher ersetzt sein. 

Bei der Herstellung des Smart Card Chips v^rd zxmachst durch den Chip- 
25 hersteller ein ROM-Maske genarmter Programmcode-Anteil, der vor allem 
das Betriebssystem enthalt, in den ROM implementiert. Anschliefiend wird, 
in der Regel durch den Smart Card Hersteller, der den Chip mit der imple- 
mentierten ROM-Maske vom Chiphersteller bezieht, die Komplettierung der 
Smart Card durchgefiihrt, bei der Erganzungen zum Betriebssystem imd 
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Anwendimgen des Smart Card Herstellers in den EEPROM implementiert 
werden. Nach erfolgter Komplettierung ist der Smart Card Chip fertig zur 
Herausgabe an den Kimden. 

5 Um plattformunabhangige und gut gegeneinander abgesicherte Anwendim- 
gen zu erstellen, eignen sich objektorientierte Prbgrammiersprachen, insbe- 
sondere Java™ der Firma Sim Microsystems Inc., sehr gut. Die Laufzeitum- 
gebimgen objektorientierter Programmiersprachen wie Java™ sind jedoch in 
der Kegel zu umfangreich, um sie ohne Weiteres in einen Smart Card Chip. 
10 implementieren zu konnen. 

Die Java Card™ Technologie der Firma Stm Microsystems Inc., die z.B. in der 
aktuellen - und lauf end aktualisierten - Version in dem Dokument "Java 
Card™ 2.2 Runtime Environment QCRE) Specification" (derzeit verfiigbar 
15 unter http://java.sim.com/products/javacard) dargelegt ist, stellt eine abge- 
wandelte Java Technologie fiir Laufzeitumgebungen mit beschrankten Sys- 
temressourcen dar, die sich auch fiir Smart Cards eignet. 

Die in der Java Card (genauer im Chip) vorgesehene Laufzeitumgebumg ge- 
20 mafi der JCRE Spezifikation umf asst zumindest die virtuelle Java-Card- 

Maschine (Java Card Virtual Machine) (JCVM) und die Java Card Applicati- 
on Programming Interface (API) Klassen, und ggf . noch weitere Komponen- 
ten. Im Zusammenhang mit der Erfindung wird unter der Virtuellen Ma- 
schine der Java Card oder virtuellen Java-Card-Maschine (im engeren Sinn) 
25 der On-Card-Anteil der virtuellen Java-Card-Maschine (im weiteren Sinn) 
verstanden. Der Begriff der virtuellen Maschine (VM) wird also im engeren 
Sinn auf gef asst und gleichgesetzt mit dem auf der Java Card vorgesehenen 
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On-Card-Anteil der VM. Neben dem On-Card-Anteil karm zusatzlich ein 
Off-Card-Anteil der VM im weiteren Sinn vorgesehen sein. 

Ein erstellter Programm-Quellcode (Soiirce Code) eines vorbestimmten Pro- 
5 gramms, z.B. eines auf eine Java Card™ zu ladenden Programms, wird bei 
der Java™ Card Technologie zunachst, wie bei der Java'^^ Technologie, mit- 
tels eines Compilers kompiliert, so dass eine Klassendatei erzeugt wird, die 
das Format eines Zwischencodes, namlich des Java Bytecode, hat, der durch 
die virtuelle Java-Maschine interpretierbar ist. Anschliefiend wird bei der 

10 Java"^^ Card Technologie, im Unterschied zur Java'^^ Technologie, der Byte- 
code der Klassendatei zusatzlich mittels eines Konverters in einen konver- 
tierten Bytecode in einer cap-Datei (cap = Card Application Protocol) konver- 
tiert. Die Compilierung und Konvertierung wird aufierhalb der Java Card, 
„Off-Card", durchgefiihrt. Die cap-Datei, tmd somit letzten Endes das vorbe- 

15 stimmte Programm, wird auf die Java Card geladen, imd der Bytecode der 
cap-Datei wird gelinkt. Beim Linken werden u.a. Zugriffsmoglichkeiten des 
mit der cap-Datei auf die Java Card geladenen Programms auf andere in der 
Java Card vorhandene Programmcode-Elemente eingerichtetd.h. es werden 
Verbindimgen zwischen den einzelnen Packages hergestellt. Beim Linken ist 

20 zu unterscheiden zwischen dem Off card-Linker und dem Oncard-Linker. 

Der Oncard-Linker ist in der Java Card (im Chip) implementiert und ist ohne 
weitere Komponenten funktionsfahig. Der Offcard-Linker benotigt zum Lin- 
ken eine Export-Datei, die Inf ormationen fiir das Linken enthalt, und die 
nicht mit in die Java Card (den Chip) geladen wird. Die virtuelle Java-Card- 

25 Maschine interpretiert schliefilich den konvertierten und gelinkten Bytecode 
der cap-Dateien und fiihrt ihn aus. 
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In der Regel ist Java-Programmcode in Form von Paketen (packages) abge- 
legt. Jedes Paket enthalt einen Tieil des Programmcodes, z3. Daten oder ein 
Oder mehrere einzelne Programme. Die einzelnen Programme konnen ent-* 
weder Systemfunktionen des Betriebssystems (in kompilierter Form: Sys- 
5 temklassen) oder Anwendungen sein. Die Strukturierung des Programmco- 
des in Pakete ist auch in der konvertierten cap-Datei beibehalten. 

In der cap-Datei enthalt jedes Paket neben dem eigentlichen Progranuncode 
zusatzlich eine Import-Komponente und eine Export-Komponente. 

10 

In der Import-Komponente ist f estgelegt, welche Zugriff smoglichkeiten das 
Paket auf andere Pakete benotigt, z.B. welche Methpden aus anderen Pake- 
ten das Paket benutzen mochte. Die benotigten Zugriffsmogiichkeiten wer- 
den beispielsweise durch eine Ref erenz „iniport<anderes Paket>'' in der Im- 
15 port-Komponente angegeben. Dabei wird eine solche „import<..>"-Ref erenz, 
die der Form nach eine Namensreferenz (Referenz, die auf einen Namen ge- 
richtet ist, z.B. auf „anderes Paket") ist, bei der Erzeugung der cap-Datei 
i.d.R. in ein sogenanntes Token umgewandelt, das der Form nach eine 
Nummernreferenz (Referenz, die auf eine Nummer gerichtet ist) ist. 

20 

In der Export-Komponente ist festgelegt, welche Zugriffsmogiichkeiten das 
Paket anderen Paketen bietet, d.h. z.B. welche Methoden das Paket anderen 
Paketen zur Benutzung zur Verfugung stellt. Die zur Verfiigung gestellten 
Zugriffsmogiichkeiten werden beispielsweise durch die Angabe einer Adres- 
25 se in der Export-Komponente erzielt, wobei durch die Adresse der Speiche- 
rort des zur Verfugimg gestellten Programmcodes angegeben ist. 
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Dass ein neu in eine Java Card geladenes Paket tatsachlich auf ein vorbe- 
stimmtes anderes Paket zugreifen und dessen Programmcode nutzen kann, 
wird durch das Linken eingeriditet. Dabei, beim Linken, ladt das neu gela- 
dene Paket Linkinformation (z.B, eine Adresse) aus der Export-Komponente 
5 des anderen Pakets in die eigene Import-Komponente. Beispielsweise wird 
beim Linken ein Token, d.h. eine aus einer „iinport''-Referenz erzeugte 
Nummernref erenz, in der Import-Komponente des neuen Pakets durch eine 
Adresse aus der Export-Komponente des anderen Pakets ersetzt. Hierdurch 
wird der Token (die Ref erenz) mit dem Benutzungswunsch durch eine tat- 
10 sachliche Adress-Verkniipfung zwischen den beiden Paketen ersetzt. Die 
Verkniipfung und damit die tatsachliche Benutzungsmoglichkeit kann nur 
eingerichtet werden, wenn dem neu geladenen Paket die Export-Kompo- 
nente des anderen Pakets, dessen Programmcode das neue Paket nutzen 
will, zur Verfiigung steht. 

15 

Die Export-Komponenten aller Pakete, die in einer Java Card implementiert 
sind, Oder eine vorbestimmte Teilmenge aller dieser Export-Komponenten, 
sind in der Export-Datei zusammengefasst. Wird vor der Komplettierung 
der Java Card ein zusatzliches (neues) Paket in die Java Card nachgeladen, 
20 wird es unter Verwendung des Offcard-Linkers und der Export-Datei ge- 

linkt, Nach der Komplettierung der Java Card kann zum Linken nur der On- 
card-Linker verwendet werden. 

Anwendungen sind in der Kegel in Form von Applets in der Java Card imp- 
25 lementiert, wobei die Applets wiederum zu Anwendungs-Paketen gruppiert 
sind. Bei den Anwendungs-Paketen gibt es sogenaimte preloaded packages 
(preissuance packages), die vor oder bei der Komplettierung in den Smart 
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Card Chip implementiert werden, und die in der Kegel durch den Smart 
Card Hersteller implementiert werden. Weiter gibt es postloaded packages 
(postissuance packages), die nach erf olgter Komplettierung in den Smart ^ 
Card Chip geladen werden, in der Regel durch den Abnehmer oder Kunden, 
5 beispielsweise ein Kreditinstitut oder eine Behorde. 

Die Inhalte (z,B. Applets bzw. Systemfimktionen) imterschiedUcher Pakete 
Bind durch Firewalls gegeneinander abgesichert, wohingegen die Inhalte 
(Applets etc.) innerhalb ein und desselben Pakets nicht mittels Firewalls ge- 
10 geneinander abgesichert sind. 

Java stellt eine Reihen von unterschiedlichen Variablentypen zur Verfiigung. 
Z.B. gibt es eine Reihe von nicht globalen, auf thren Kontext beschrankten 
und d)mamisch erzeugten Variablen, z.B. Instanzvariablen oder gleichbedeu- 

15 tend Objektvariablen (instance variables), lokale Variablen (local variables) 
imd Methodenparameter (method parameters). Instanzvariablen, lokale Va- 
riablen, Methodenparameter haben gemeinsam, dass sie dynamisch walv 
rend der Laufzeit eines Programms mit dem Objekt (= Instanz einer Klasse), 
dem Ablauf (z.B. Programmschleife), der Methode etc. erzeugt werden, zu 

20 dem sie gehoren und nur so lange existieren wie das Objekt, der Ablauf bzw. 
die Methode existiert, d.h. sie sind transient. Zudem sind sie nicht global, 
d.h. sie sind nur innerhalb des Kontexts (d.h. innerhalb des Objekt, des Ab- 
lauf s bzw. der Methode) verwendbar, in bzw. mit dem sie erzeugt worden 
sind. Uber den Kontext hinaus verhindert die Firewall, dass die Variablen 

25 verwendet werden, d.h. der Zugriff auf die Variablen von aufierhalb des 
Kontext ist durch die Firewall verhindert. 
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Der fiir Instanzvariablen reservierte Speicherbereich liegt auf dem heap- 
Speicher, im nichtfliichtigen EEPROM (oder alternativ im Flash-Speicher), 
Der fiir lokale Variablen reservierte Speicherbereich liegt auf dem Stack- ^ 
Speicher, im RAM, und hat nur eine kurze Lebensdauer, namlich die Dauer 
5 der Methoden-Ausfiihrung. 

Der Nachteil der nicht globalen Variablen ist, dass sie axifierhalb ihres Kon- 
text nicht verwendbar sind. 

10 Neben den bereits genannten Variablen gibt es als die einzigen globalen 

(s.u.) Variablen bei Java die Klassenvariablen, die statisch erzeugte Variablen 
sind (class variables, static variables). 

Klassenvariablen (gleichbedeutend verwendeter Begriff: static Variablen) 
15 sind globale Variablen, d.h. sie sind nicht an einzelne Instanzen einer Klasse 
(= einzelne Objekte) gebunden. Klassenvariablen werden statisch deklariert, 
wobei der fiir die Klassenvariablen reservierte Speicherbereich im EEPROM 
liegt, also in einem nichtfliichtigen Speicherbereich der Java Card. 

20 Schreibzugriff e auf den EEPROM sind langsam und kosten daher viel Zeit. 
Aus diesem Grund ist der Zugriff auf Klassenvariablen langsam, weshalb die 
Performance eines Programms, das Klassenvariablen verwendet, gering ist. 
Zum Anderen erlaubt ein EEPROM lediglich eine Hochstzahl von typi- 
scherweise 100 000 Schreibzyklen, weshalb es wiinschenswert ist, Schreib- 

25 zugriffe auf den EEPROM wo moglich zu vermeiden. Die Verwendung von 
Klassenvariablen, insbesondere in Fallen, wenn nur eine kurze Lebensdauer 
der Variablen erforderlich ist, verlangsamt somit die Performance des Pro- 
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grammablaufs und belastet durch die dabei erfolgenden Schreibprozesse den 
EEPROM. 

Andererseits besteht der Bedarf, Variablen global, also tinabhangig vom 
5 Kontext eines speziellen Objekts, Pakets, einer speziellen Methode etc. zu 
verwenden, beispielsweise fiir den Austausch von Variablen zwischen unter- 
schiedlichen Kontexten (Objekten, Paketen, Methoden) etc.. Derzeit ist diese 
Moglichkeit nur durch Klassenvariablen gegeben, die die weiter oben ge- 
nannten Nachteile haben, wie starke Belastuxig des EEPROM tind Langsam- 
10 keit. 

Auf gabe der Erfindung ist es daher, einen Smart Card Chip mit einer virtu- 
ellen Java-Card-Maschine und einem fiir globale Variablen reservierten Spei- 
cherbereich zur Verf iigung zu stellen, der einen einf achen, schnellen und fiir 
15 den Chip schonenden Zugriff auf die globalen Variablen ermoglicht. 

Die Auf gabe wird gelost durch ein Variablen-System nach Anspruch 1. Vor- 
teilhafte Ausgestaltungen der Erfindung sind in den abhangigen Ansprii- 
chen angefiihrt. 

20 

Der Smart Card Chip gemafi Anspruch 1 hat einen fiir globale Variablen re- 
servierten Variablen-Speicherbereich, der im fliichtigen Arbeitsspeicher re- 
serviert ist, beispielsweise im RAM. Zugriffe auf den fliichtigen Arbeitsspei- 
cher sind schnell und zudem wird dadurch, dass der fliichtige Arbeitsspei- 
25 cher verwendet wird, der nichtfliichtige Anwendungsspeicher, insbesondere 
EEPROM Oder ein Flash-Speicher, geschont. Hierdurch ermoglicht der Chip 
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gemafi Anspruch 1 einf achen, schnellen und fiir den Chip schonenden 
Zugriff auf die globalen Variablen. 

Daher ist gemafi Anspruch 1 ein Smart Card Chip mit einer virtuellen Java- 
5 Card-Maschine und einem fiir globale Variablen reservierten Speicherbereich 
gesc±ia£f en, der einen einf achen, schnellen und fiir den Chip schonenden 
Zugriff auf die globalen Variablen ermoglicht. 

Die Erfindung ist insbesondere fiir Anwendungsfalle fiir globale Variablen 
10 gut geeignet, bei denen die Variablen zwar global sein miissen, z.B. weil sie 
iiber Kontextgrenzen hinaus verfiigbar sein miissen, bei denen aber eine lan- 
ge Lebensdauer der Variablen nicht erf orderlich ist. Denn der (schnelle) 
RAM-Speicher, in dem der Speicherbereich fiir die Variablen reserviert ist, 
und in dem die Variablen bei Bedarf angelegt werden, ist fliichtig. Folglich 
15 werden die angelegten Variablen geloscht, sobald die Energieversorgimg des 
RAM-Speichers imterbrochen wird. 

Vorzugsweise ist der Variablen-Speicherbereich statisch reserviert, bei- 
spielsweise dadurch, dass der Variablen-Speicherbereich fiir Klassenvariab- 

20 len reserviert ist (gleichbedeutend: Variablen vom Typ static), da der 

Zugriff auf die Variablen bei einer statischen Reservierung besonders schnell 
ist. Ein Zugriff (Lesezugriff bzw. Schreibzugriff) auf den statisch reservierten 
Variablen-Speicherbereich bedeutet, dass eine statisch reservierte Variable 
(Variable vom Typ static) verwendet (gelesen oder liberschrieben) wird. Da 

25 bei der Verwendimg von statisch reservierten Variablen keine Firewall- 
Priifung durchgefuhrt wird, hat die statische Reserviertmg des Variablen- 
Speicherbereichs den zusatzlichen Vorteil, dass der Zugriff auf die Variablen 
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schneller ist als werm der Variablen-Speicherbereich d3mamisch, wahrend 
der Laufzeit des Programms reserviert wiirde. JFolglich ist es besonders be- 
vorzugt, dass der Variablen-Speicherbereich statisch reserviert ist. 

5 Welter ist es bevorzugt, dass solche Programme auf den Variablen-Speicher- 
bereich zugreifen konnen, die auf den Variablen-Speicherbereich linken kon- 
nen. Dabei ist weiter vorzugsweise das Vermogen eines Programms, auf den 
Variablen-Speicherbereich linken zu konnen, dadurch erzielt, dass dem Pro- 
gramm zum Linken eine Export-Komponente auf dem Smart Card Chip zur 

10 Verfiigung steht. Der Variablen-Speicherbereich erscheint fiir ein Programm, 
das darauf zugreifen will, wie ein fremdes Programm. Daher benotigt das 
Programm, das auf den Variablen-Speicherbereich zugreifen will, die Export- 
Information des f remden Programms, das den Variablen-Speicherbereich 
geschaffen hat. Vorzugsweise hat also ein Programm, das den reservierten 

15 Variablen-Speicherbereich nutzen mochte, zvim Linken die Export- 
Komponente eines fremden Programms zur Verfiigung, das den Variablen- 
Speicherbereich geschaffen hat. 

Weiter sind vorzugsweise solche Programme davon ausgeschlossen sind, 
20 den Variablen-Speicherbereich zu nutzen, die nicht auf den Variablen- 
Speicherbereich linken kormen. Das Unvermogen eines Programms, auf den 
Variablen-Speicherbereich linken zu konnen, ist vorzugsweise dadurch er- 
zielt, dass dem Programm zum Linken eine Export-Komponente des Smart 
Card Chips vorenthalten ist. 

25 

Weiter bevorzugt ist der Variablen-Speicherbereich dadurch reserviert, dass 
in einem Systemspeicher des Chips ein entsprechendes Java Paket abgelegt 
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ist, das vorzugsweise nur die Reservierung des Variablen-Speicherbereichs 
enthalt. Ein solches Java Paket mit dem Namen z,B. 

,,com.gieseckedevrient.javacard.os.commonram'', 
das Speicherplatz fiir eine Mehrzahl von statischen Variablen „myRamVa- 
5 rA", „myRamVarB", etc. vom Datentyp short und Byte und Int reserviert, 
kann beispielsweise folgende Gestalt haben: 

package com.gieseckedevrient.j avacard.os.commonram; 
static short myRamVar A; 
10 static short myRamVarB; 

etc. 

Das Java Paket wird im Systemspeicher (ROM, ggf . auch Flash-Speicher) ab- 
gespeichert. Bei der spateren Verwendung des Java Pakets werden die ent- 
15 sprechenden Daten, d.h. die statischen, globalen Variablen vom Typ short. 
Byte, Int im RAM abgelegt. 

Weiter ist es bevorzugt, dass auf den Variablen-Speicherbereich nur im Sys- 
temspeicher (ROM, Flash) abgespeicherte Programme zugreifen koimen. 
20 Alternativ oder zusatzlich konnen vorzugsweise auf den Variablen- 
Speicherbereich nur Programme zugreifen, die bis zum Abschluss der Kom- 
plettienmg des Smart Card Chips in dem Smart Card Chip implementiert 
worden sind. 

25 GemaJS einer bevorzugten Ausfiihrungsf orm w^ird nur fiir Pakete, die bis zur 
Komplettierxmg implementiert werden, zum Linken die Export-Komponente 
zur Verfugung gestellt. Ein geladenes Paket, das bis zur Komplettierung 
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implementiert wird, wird vorzugsweise mit dem Off card-Linker tind der 
Export-Datei gelinkt. Dadurch wird die Linkinformation zum Linken auf den 
Variablen-Speicherbereich aus der Export-Komponente des Java Pakets, das 
den Variablen-Speicherbereich reserviert, in die Import-Komponente des 
5 geladenen Pakets geladen. Die Folge ist, dass das geladene Paket auf den 
reservierten Variablen-Speicherbereich zugreifen kann und dort, im RAM, 
die RAM-Variablen benutzen kann. Pakete, die nach der Komplettierung in 
die Java Card bzw. den Chip implementiert werden, haben in ihren Import- 
Komponenten nicht die Linkinformation aus der Export-Komponente des 
10 Java Pakets, das den Variablen-Speicherbereich reserviert hat. Daher konnen 
gemafi der bevorzugten Ausfiihrxmgsform nach der Komplettierung imple- 
mentierte Pakete die erfindungsgemafien RAM-Variablen nicht benutzen, 
d.h. nicht auf den reservierten Variablen-Speicherbereich im RAM zugreifen. 

15 Die virtuelle Java-Card-Maschine ist vorzugsweise derart gestaltet, imd da- 
bei bei Bedarf gegeniiber der virtuellen Java-Card-Maschine gemafi der Java 
Card VM Spezifikation modifiziert, dass sie auf Grundlage des im fliichtigen 
Arbeitsspeicher (RAM) reservierten Variablen-Speicherbereichs die Verwen- 
dung von globalen Variablen im RAM ermoglicht. 

20 

Insbesondere sind bei Bedarf die Befehle „getstatic'' und „putstatic'' der 
virtuellen Java-Card-Maschine gegeniiber den Befehlen „getstatic" und 
„putstatic" virtuellen Java-Card-Maschine gemafi der Java Card VM Spezi- 
fikation modifiziert. 

25 

Vorzugsweise sind die bei Bedarf vorgenommenen Modifizierungen oder 
Anderungen an der virtuellen Java-Card-Maschine derart vorgenommen. 
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dass die Modifizienmgen / Anderungen bei der Verwendxing der VM nach 
aufien nicht qualitativ erkennbar sind. Dass die Modifizierungen qualitativ 
nicht erkennbar sind, bedeutet insbesondere, dass der Smart Card Chip einer 
vorbestiimnten Java Card Spezifikation geniigt, der der Chip ohne die Modi- 
5 fikationen ebenfalls geniigen wiirde. Quantitativ konnen die Modifizierun- 
gen optional nach aufien erkennbar sein, z.B. kann nach aufien erkennbar 
sein, dass das Verwenden der erfindiingsgemafien globalen RAM-Variablen 
schneller ist als das Verwenden von bekannten globalen Variablen aus dem 
Stand der Technik. Insbesondere sind die bei Bedarf an den Befehlen 

10 „getstatic'' und „putstatic" vorgenommenen Anderungen vorzugsweise 
derart durchgefiihrt, dass das Verwenden (z.B. Anlegen, Variablenwert an- 
dern) von static Variablen unter Verwendung der Befehle „getstatic" und 
„putstatic" unverandert ist gegeniiber dem Verwenden (z.B. Anlegen, Va- 
riablenwert andern) von static Variablen gemafi der Java Card VM Spezifi- 

15 kation. 

Dass die Anderungen nach aufien nicht qualitativ erkennbar sind, wird bei- 
spielsweise dadurch erreicht, dass ein Variablen-Speicherbereich fiir globale 
Variablen im RAM reserviert wird, wobei fiir die Reservierung eine ansons- 
20 ten der Java Card VM Spezifikation geniigende Variablen-Deklaration ver- 
wendet wird, beispielsweise eine Deklaration von static Variablen, nur mit 
dem Unterschied, dass die static area im RAM statt im EEPROM vorgesehen 
ist. 

25 Die Einhaltung der Spezifikationen wird vorzugsweise ferner dahingehend 
gewahrleistet, dass ein normaler Benutzer den reservierten Variablen- 
Speicherbereich nicht benutzen kann, d.h. keine erfindungsgemafien RAM- 
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Variablen benutzen karm, da ihm die Linkinformation fehlt, weil ihm die 
zum Linken erforderliche Export-Datei vorenthalten ist. Beispielsweise wird 
die Export-Datei beim Hersteller der Smart Card verwahrt und gegeniiber ' 
Benutzern wie Abnehmern von Smart Cards geheim gehalten. Vorzugsweise 
5 konnen nur Programmentwickler von Systemprogrammen (und wahlweise 
zusatzlich von preloaded packages), die vor der Komplettierung gelinkt 
werden, die erfindungsgemafien RAM- Variablen verwenden, da nur diesen 
Programmentwicklem von Systemprogrammen (und ggf . preloaded packa- 
ges) die geheime Export-Datei und somit die zum Linken auf den reservier- 

10 ten Variablen-Speicherbereich erforderliche Linkinformation zur Verfiigimg 
steht. Nur Programmentwickler von Systemprogrammen (xmd ggf. preloa- 
ded packages) sind also von der allgemeinen Geheimhaltung der Export- 
Datei ausgenommen. Abnehmer von Smart Cards, die nach der Komplettie- 
rung der Smart Card Programme (z.B, Anwendungen) in die Smart Card 

15 (bzw. in den Smart Card Chip) laden, konnen zum Linken hingegen nur den 
Oncard-Linker verwenden, der die Linkinformation zum Linken auf den 
reservierten Variablen-Speicherbereich im RAM nicht hat. 

Im folgenden wird die Erf indung anhand von Ausfiihrtingsbeispielen xmd 
20 imter Bezugnahme auf die einzige Figur 1 der Zeichnung naher erlautert. 

Fig. 1 zeigt eine schematische Darstellimg einer Java Card mit einem darin 
implementierten RAM package 5 , durch das ein Variablen- 
Speicherbereich 18 im RAM der Java Card statisch reserviert ist, ge- 
25 mafi einer bevorzugten Ausfuhrungsf orm der Erfindung. 
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Die Java Card aus Fig. 1 hat einen nichtfluchtigen Systemspeicher 1, namlich 
den ROM 1, einen nichtfluchtigen Anwendungsspeicher 2, namlich den 
EEPROM 2, und einen flxichtigen Arbeitsspeicher 3, namlich den RAM 3. * 

5 Im ROM 1 sind die virtuelle Java-Card-Maschine VM 4 und weiterer nativer 
Code implementiert. Zudem sind im ROM 1 eine Reihe von Paketen Pckgl, 
Pckg2, ... Pckgn mit unterschiedlichen Inhalten, zum Teil Systemfunktionen 
und zum Teil Anwendimgen, implementiert. Aufierdem ist im ROM 1 das 
erfindungsgemafie RAM package 5 implementiert, also das Java Paket, 

10 durch welches der Variablen-Speicherbereich 18 im RAM reserviert ist. Im 
EEPROM 2 sind mehrere vor der Komplettierung in die Java Card geladene 
Pakete mit Anwendungen, namlich mehrere preloaded EEPROM packages 
16, abgespeichert. Zudem enthalt der EEPROM 2 einen heap-Speicher 19 mit 
dynamischen Daten (Dynamic Data), mehrere Puff erspeicher (Buffers) und 

15 einen Bereich mit nativen Daten. Der RAM 3 enthalt native RAM-Daten, den 
durch das RAM package reservierten Variablen-Speicherbereich 18 (RamP.- 
Data), zwei Pufferspeicher (Buffer), einen Arbeitsspeicherbereich, der auf 
Anfrage geloscht wird (COD, Clear On Demand) und einen Arbeitsspeicher- 
bereich, der bei Reset, also bei Riicksetzen, geloscht wird (COR, Clear On 

20 Reset). 

Die virtuelle Maschine VM 4 in Fig. 1 enthalt beispielsweise die Befehle der 
VM 4 wie z.B. „putstatic" 7, mit dem sich eine static Variable zur Laufzeit 
andern lasst, wie durch den vergrofierten Ausschnitt 7 der VM mit der Be- 
25 schriftung „Putstatic'' angedeutet ist. 
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Im beschriebenen Beispiel von Fig. 1 gibt es weiter eine in der Java Card 
implementierte Zugriffstabelle (SAT, segment allocation table), die u.a. die 
Anfangsadressen der in der Java Card implementierten Pakete (packages) * 
enthalt. 

5 

Die Zugriffstabelle SAT enthalt insbesondere fiir das RAM package einen 
static area descriptor 8, d.h. einen in dem RAM package 5 enthaltenen De- 
skriptor 8 (oder eine Angabe), der einen Anfang und eine Grofie eines be- 
stimmten Adressbereichs als Speicherbereich fiir statisch deklarierte (reser- 

10 vierte) Variablen angibt. Der Deskriptor 8 (static area descriptor) enthalt 
^zwei Teilangaben, namlich die Anfangsadresse des Adressbereichs und die 
GroISe des Adressbereichs. Die Anfangsadresse ist so gewahlt, dass der 
durch den static area descriptor 8 bestimmte Adressbereich im RAM 3 der 
Java Card liegt, wie durch die Pfeile 12, 13 angedeutet ist, die vom Deskrip- 

15 tor 8 (static area descriptor) zum RAM 3 verlaufen. Durch die derart getrof- 
fene Auswahl der Anfangsadresse (d.h. Auswahl der Anfangsadresse so, 
dass der reservierte Variablen-Speicherbereich im RAM liegt) ist eine direkt 
auf den RAM-Speicher gerichtete Zugriffsinformation gebildet. Dass der De- 
skriptor 8 (static area descriptor) auf eine Adressangabe im RAM verweist, 

20 stellt eine Anderung gegeniiber der Java Card VM Spezifikation dar, die je- 
doch nach aufien nicht erkennbar ist. 

Das in Fig. 1 dargestellte Paket 6 mit der Nimimer „n"> bezeichnet mit 
„Pckgn'', ist ein preloaded package, d.h. ein Paket, das vor der Komplettie- 
25 rung der Java Card in der Java Card implementiert worden ist, und enthalt 
im ROM-Speicher 1 der Java Card abgelegten Paket-Code 9, wie durch den 
vergrofierten Ausschnitt 9 „Preloaded Pack. Code" angedeutet ist. Der Pa- 
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ket-Code 9 des preloaded package 6 wiederum enthalt Code fiir einen Kon- 
stantenpool 10 („Const. Poor") und Code 11 fiir den Befehl „putstatic" der 
VM. Durch „putstatic" 11 im Code des preloaded package 6 (Pckgn) wird 
unter Verwendiing des Konstantenpools 10 eine Variable vom Typ static 
5 adressiert, und zwar im RAM 3, im reservierten Variablen-Speicherbereich 
18, wie durch die Pfeile 14, 15 angedeutet ist, die von „Code putstatic" zu 
„Const. Pool ..." (Pfeil 14) und von „Const. Pool ..." zu „RamP. Data" (Pfeil 
15) verlaufen. Das preloaded package Paket Pckgn 6 wurde durch den Off- 
card-Linker und unter Verwendung der Export-Datei der Java Card gelinkt. 

10 Dabei wurde das preloaded package Paket Pckgn 6 mit Linkinf ormation des 
RAM package 5 ausgestattet, insbesondere mit der Adresse, die im Deskrip- 
tor 8 fur static Variablen (static area descriptor) steht. Hierdurch hat das 
preloaded package Pckgn 6 die Linkinformation des RAM package 5. Folg- 
lich kann das preloaded package Pckgn 6 den reservierten Variablen- 

15 Speicherbereich 18 des RAM package 5 benutzen, also erfindungsgemafie 
globalen Variablen (RAM static Variablen) benutzen. 

Bei dem Beispiel aus Fig. 1 kann ein postloaded package 16, das im EEPROM 
implementiert ist, nicht auf den im RAM 3 reservierten Variablen- 
20 Speicherbereich 18 zugreifen, so dass das postloaded package 16 im 

EEPROM keine erfindungsgemafien globalen Variablen im RAM benutzen 
kann. Nur Pakete im Systemspeicher ROM konnen die globalen Variablen im 
RAM benutzen. 

25 Gemafi alternativen Ausfiihrungsformen konnen auch preloaded packages 
im EEPROM die globalen Variablen im RAM benutzen. Die preloaded pa- 
ckages im ROM haben darm, wie die packages im Systemspeicher ROM 
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auch, die vom Offcard-Linker in der Export-Datei bereitgestellte Adressin- 
formation, mit der sie auf den reservierten Variablen-Speicherbereich linken 
konnen, so dass sie den reservierten Variablen-Speicherbereich im RAM fiir 
Variablen benutzen konnen. 



5 



wo 2005/055052 



19 

Patentanspriiche 



PCT/EP2004/013797 



1. Smart Card Chip mit einem nichtfliichtigen Systemspeicher (ROM, 
Flashl), einer in dem nichtfliichtigen Systemspeicher (ROM, Flashl) imple- 

5 mentierten virtuellen Java-Card-Maschine, einem nichtfliichtigen Anwen- * 
diingsspeicher (EEPROM, Flash2), einem fliichtigen Arbeitsspeicher (RAM) 
und einem fur globale Variablen reservierten Variablen-Speicherbereich, 
wobei der Variablen-Speicherbereich im fliichtigen Arbeitsspeicher (RAM) 
reserviert ist. 

10 

2. Smart Card Chip nach Anspruch 1, wobei auf den Variablen- 
Speicherbereich nur im Systemspeicher (ROM, Flash) abgespeicherte Pro- 
gramme zugreif en konnen. 

15 3. Smart Card Chip nach Anspruch 1 oder 2, wobei auf den Variablen- 
Speicherbereich nur Programme zugreif en konnen, die bis zum Abschluss 
der Komplettiertrng des Smart Card Chips in dem Smart Card Chip imple- 
mentiert worden sind. 

20 4. Smart Card Chip nach einem der Anspriiche 1 bis 3, wobei der Vari- 
ablen-Speicherbereich statisch reserviert ist. 

5. Smart Card Chip nach einem der Anspriiche 1 bis 4, wobei der Vari- 
ablen-Speicherbereich durch eine direkt auf den Arbeitsspeicher (RAM) ge- 
25 richtete Zugriff sinf ormation reserviert ist. 



6. Smart Card nach einem der Anspriiche 1 bis 5, wobei solche Pro- 
gramme auf den Variablen-Speicherbereich zugreifen konnen, die auf den 
Variablen-Speicherbereich linken konnen. 
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7. Smart Card Chip nach Anspruch 6, wobei das Verraogen eines Pro- 
gramms, auf den Variablen-Speicherbereich linken zu kormen, dadurch er-» 
zielt ist, dass dem Programm zum Linken eine Export-Komponente auf dem 

5 Smart Card Chip zur Verfiigimg steht. 

8. Smart Card Chip nach einem der Anspriiche 1 bis 7, wobei solc±Le 
Programme davon ausgeschlossen sind, den Variablen-Speicherbereich zu 
nutzen, die nicht auf den Variablen-Speicherbereich linken konnen. 

10 

9. Smart Card Chip nach Anspruch 8, wobei das Unvermogen eines Pro- 
gramms, auf den Variablen-Speicherbereich linken zu konnen, dadurch er- 
zielt ist dass dem Programm zum Linken eine Export-Komponente des 
Smart Card Chips vorenthalten ist. 

15 

10. Smart Card Chip nach einem der Anspriiche 1 bis 9, wobei der Vari- 
ablen-Speicherbereich durch ein in dem Smart Card Chip implementiertes 
Java Paket (RAM package) reserviert ist. 

20 11. Smart Card Chip nach Anspruch 10, wobei das Java Paket (RAM pa- 
ckage) im Systemspeicher (ROM, Flashl) implementiert ist. 

12. Smart Card Chip nach Anspruch 10 oder 11, wobei das Java Paket 
ausschliefilich die Reservierung des Variablen-Speicherbereichs enthalt. 

25 

13. Smart Card Chip nach einem der Anspriiche 10 bis 12, wobei eine Ex- 
port-Komponente des Java Pakets (RAM package), in der die zum Linken 
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auf den reservierten Variablen-Speicherbereich erforderliche Linkinformati- 
on enthalten ist, nicht in dem Smart Card Chip implementiert ist. 

14. Smart Card Chip nach einem der Anspriiche 1 bis 13, wobei die virtu- 
5 elle Java-Card-Maschine derart gestaltet ist, imd dabei bei Bedarf modifiziert 
ist, dass sie auf Grundlage des im fliichtigen Arbeitsspeicher (RAM) reser- 
vierten Variablen-Speicherbereichs die Verwendimg von globalen Variablen 
im RAM ermoglicht. 

10 15. Smart Card Chip nach Anspruch 14, wobei die virtuelle Java-Card- 
Maschine derart modifiziert ist, dass die Modifizienmgen nach aufien hin 
nicht quaUtativ erkennbar sind, insbesondere dass der Smart Card Chip einer 
vorbestimmten Java Card Spezifikation geniigt, welcher der Chip ohne die 
Modifikationen ebenfalls geniigen wiirde. 

15 

16. Chipmodul mit einem Smart Card Chip gemafi einem der Anspriiche 
1 bis 15. 

17. Datentrager, insbesondere Java Card, mit einem Smart Card Chip ge- 
20 mafi einem der Anspriiche 1 bis 15 und/oder einem Chipmodul gemafi An- 
spruch 16. 

18. Verf ahren zimi Reservieren eines Variablen-Speicherbereichs in einem 
Smart Card Chip, der aufweist: eine nichtflxichtigen Systemspeicher (ROM, 

25 Flashl), eine in dem nichtflxichtigen Systemspeicher (ROM, Flashl) imple- 
mentierte virtuelle Java-Card-Maschine, einen nichtflxichtigen Anwendimgs- 
speicher (EEPROM, Flash2) und einen fliichtigen Arbeitsspeicher (RAM), 
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wobei bei dem Verfahren ein Java Programmcode in dem Smart Card Chip 

implementiert wird, durch den ein Variablen-Speicherbereich fiir globale 
Variablen im fliichtigen Arbeitsspeicher (RAM) reserviert wird, 

5 19. Verfahren nach Anspruch 18, wobei als Java Programmcode eine Java 
Paket (RAM package) implementiert wird. 

20. Verfahren nach Anspruch 19, wobei eine Export-Komponente des Ja- 
va Pakets, in der die zum Linken auf den Variablen-Speicherbereich erfor- 

10 derliche Linkinf ormation enthalten ist, nicht in dem Smart Card Chip imp- 
lementiert wird. 

21. Verfahren nach einem der Anspriiche 18 bis 20, wobei eine zum Lin- 
ken auf den reservierten Variablen-Speicherbereich erf orderliche Export- 

15 Datei nur solchen Programmen zum Linken zur Verfiigimg gestellt wird, die 
auf den Variablen-Speicherbereich zugreif en konnen soUen. 
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